home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / INTERNET / ACORNET / ACORN-ST / ACRNET21 / !AcornetA_Docs_FreeSMTP < prev    next >
Encoding:
Text File  |  1997-02-28  |  36.8 KB  |  1,001 lines

  1. !FreeSMTP 1.21
  2. ==============
  3.  
  4. Contents:
  5.     Copyright & Disclaimer
  6.     Important Changes in this Version
  7.     Installation Instructions
  8.     Upgrading from Earlier versions
  9.     Configuration Instructions
  10.         Why does all email get sent to "localhost"
  11.     Operating Advice
  12.         for people with permanent links
  13.         for people with transient dialup links
  14.     Running & Stopping !FreeSMTP
  15.     What to do if you get the error message:
  16.         Loopback interface is not configured/up
  17.         Loopback interface is configured - but not up
  18.     Kicking the sender
  19.     Activity log
  20.     References
  21.     Bug Reporting
  22.     Technical Details
  23.         MX records explained
  24.         Security Considerations
  25.         Ident
  26.     ChangeLog
  27.  
  28.  
  29. **** WARNING: Incorrect configuration can cause you to be in breach
  30. **** of your provider's terms & conditions.  Full details under the
  31. **** configuration section below, in the subsection "forwarder"
  32.  
  33.  
  34.  
  35.  
  36. Copyright & Disclaimer
  37. ----------------------
  38.  
  39. This program is copyright (C) Stewart Brodie, 1996, 1997
  40.  
  41. The author accepts no liability for any damage or loss of any kind incurred,
  42. or allegedly incurred, by the use, or misuse, of this software.  The program
  43. may do its absolute best to ensure that incoming mail is either stored
  44. successfully in the incoming (or outgoing) mail spool appropriately, or that
  45. the sender is informed that the delivery attempt was unsuccessful and should
  46. be retried (or not as appropriate).
  47.  
  48. Having said all that, I do want people to use it and find any problems.  I'm
  49. afraid that some people's attitude make all those disclaimers necessary.  For
  50. normal usage, there shouldn't be any problem, and the programs try very hard
  51. indeed to prevent any loss occurring (eg. by not acknowledging successful
  52. reception of an e-mail until it has been successfully stored in the spool
  53. directory completely).  If the program fails, then in the vast majority of
  54. cases the upstream SMTP will have received a rejection from this program
  55. (unrequested connection termination counts as a rejection unless the 250
  56. response to the final '.' of a DATA body is received at the sender).  If the
  57. sender half of this software fails, then it it will construct a failure
  58. message and return that directly to the message originator.
  59.  
  60.  
  61.  
  62. Important Changes in this Version
  63. ---------------------------------
  64.  
  65. Issuing a DATA command at the wrong point no longer results in two responses
  66. being sent.
  67.  
  68. From older versions:
  69.  
  70. A bug whereby the sender fails to start due to a memory shortage and then
  71. will never start again (until FreeSMTP is reloaded) has been cured.
  72.  
  73. I've implemented a fix for the forwarding rules which should make the
  74. forwarder lines behave completely intuitively.  If people find problems,
  75. I'd like to know bout them, please.
  76.  
  77.  
  78. Installation Instructions
  79. -------------------------
  80.  
  81. Installation should be fairly simple and trouble free provided these
  82. instructions are followed carefully.  You will NEED Newsbase 0.55 or later
  83. in order for this to work properly - it will not like 0.54.  I have tried
  84. to include as much details as possible, so don't worry about the apparent
  85. length of it.
  86.  
  87. * Copy the Transports directory into the !Newsbase directory to install the
  88. interface programs in Newsbase. (You may find that you have to restart
  89. Newsbase now to get it to recognise the newly present transport).
  90.  
  91. * Copy the !FreeSMTP directory into a directory containing your other
  92. Internet applications, and run it in its new home (it will fail to start
  93. because there is no configuration file, but this step is necessary in
  94. order to reset the system variables to point to the correct directory)
  95.  
  96. * Open the Newsbase Transport Control window, and in the middle portion
  97. of this window, choose "in_smtpd" off the Transport menu.  You should now see
  98. the description "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)" or similar.  If
  99. you fail to get this far, then you may have forgotten to restart Newsbase or
  100. to rerun !FreeSMTP.
  101.  
  102. * Switch on the Check arrivals new mail option.
  103.  
  104. * Follows the instructions in the Configuration Instructions below
  105.  
  106. * Ensure you have a DNS resolver configuration file.  If you do not have a
  107. DNS resolver installed on your system, then you will need to get one.  You
  108. can find this out by looking for a file in !Internet.Files (or
  109. !FreeUser.Files or !InetSuite.Internet.Files) called "resconf".  If this is
  110. present, then you have already got the necessary file installed.  The
  111. resolver module is NOT used, but the configuration file it uses IS used by
  112. these programs (FreeNet (by Tom Hughes) comes with InetDB and its
  113. installation instructions; ArcWeb (my program) comes with just the
  114. installation instructions necessary)
  115.  
  116.  
  117. Upgrading from Earlier versions
  118. -------------------------------
  119.  
  120. Reinstall the Transports into !Newsbase.  If you changed the log file
  121. locations in !Run, re-edit the *new* !Run since this contains new
  122. system variables that are required.
  123.  
  124. Your mail is received into a different directory than before version 1.14.
  125. This makes it compatible with the KA9Q directory structure.
  126.  
  127. You should read the section on 'noiconbar' in the configuration section as
  128. this is a new command.
  129.  
  130.  
  131. Configuration Instructions
  132. --------------------------
  133.  
  134. There is a single configuration file for !FreeSMTP which is stored
  135. inside the !FreeSMTP directory.  This is deliberately entirely made
  136. up of comments so that the programs will refuse to load before you
  137. have edited the configuration.  You should find that you can skim
  138. through this section, modifying the file as you go.
  139.  
  140. (If !FreeSMTP.smtp-conf does not exist, then either copy it from defaultcnf
  141. in the same directory, or click on Setup in the Newsbase Transport Control
  142. window which will do this for you)
  143.  
  144. The configuration file is a sequence of directives which tell the
  145. software what your machine's real name is, what e-mail domains it
  146. hosts, and which domains it relays mail for (if any).  I have tried
  147. to provide as much flexibility as possible whilst keeping it as
  148. simple as possible for the vast majority of cases (take a look at an
  149. /etc/sendmail.cf file on a UNIX system to see how hairy it can become :-)
  150.  
  151. To edit the configuration file, choose the "in_smptd" transport in the
  152. Newsbase "Transport Control" window.  You should then see the description
  153. message "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)".  To set up the Newsbase
  154. bit, ensure that "Check arrivals: new mail" is set; Route outgoing mail is
  155. set, and a smarthost is placed in the gateway box for mail(**).  Also set
  156. in_smtpd as the Def mail route.  Then, you should click on the Setup button
  157. which will open the configuration file in your text editor ready for you
  158. to set your own site details.
  159.  
  160. (**) If you set the gateway to be your own machine, then you MUST have
  161.      an appropriate forwarder line as described below.  The line you
  162.      will need will be "forwarder * provider's-smarthost".
  163.  
  164. Provided you have set up the forwarder lines, you can tell any software
  165. you have to send outgoing mail to 'localhost'.  This will result in it
  166. being sent to the server which will then route it using the rules in
  167. smtp-conf without consulting Newsbase.
  168.  
  169. There are brief comments in the configuration file to remind you what each
  170. section is for, but these are elaborated here.  The order of the sections is
  171. not important, although the order of declarations of the same type IS
  172. important (see below for reasons) For each section I have given the syntax,
  173. an example for a Demon DialUp user with a nodename of 'customer',
  174. (applicable to other static IP single host systems too), an example for a
  175. host on a network handling mail for that network, and my own setup.
  176.  
  177.  
  178. hostname
  179. ========
  180.  
  181. Syntax:   hostname <Fully Qualified Domain Name (FQDN)>
  182. Demon DU: hostname customer.demon.co.uk
  183. Network:  hostname mail.an.org.uk
  184. My Setup: hostname delenn.ecs.soton.ac.uk
  185.  
  186. This gives the *full* hostname(s) of the machine running this software.
  187. Hosts may have more than one name in some circumstances, and this is
  188. allowed by having multiple hostname lines, although the *first* line
  189. found in the file is the one used to identify the server to remote
  190. hosts when it needs to (eg. when greeting SMTP clients)
  191.  
  192. localdomain
  193. ===========
  194.  
  195. Syntax:   localdomain <Fully Qualified Mail Domain> [<alias name>]
  196. Demon DU: localdomain customer.demon.co.uk
  197. Network:  localdomain an.org.uk
  198. My Setup: localdomain delenn.ecs.soton.ac.uk soton
  199.  
  200. [and in My Setup, <SMTPServer$Aliases>.soton contains the line:
  201. S.N.Brodie snb94r
  202. ]
  203.  
  204. This gives the local *mail* domain(s) handled by the software.  These
  205. mail domains are the things you see after the @ in mail addresses.
  206. When mail arrives, the destination is checked to see if there is any
  207. @ character in it.  If there is NOT, then the value of the *first*
  208. localdomain directive is assumed.  (This is so that the alias and user
  209. list functions can determine which set of aliases to apply)
  210.  
  211. Next, the bit after the @ is compared against each localdomain directive in
  212. turn.  If it matches any one of them, then the domain part is dropped. Next,
  213. if an alias name was specified for that localdomain, then the bit before the
  214. @ is looked up in <SMTPServer$Aliases>.aliasname to see if was a mail alias,
  215. and if so, the mail address is rewritten to match the definition of the
  216. alias.  The format of that file is described below.  You MUST be careful with
  217. that file.
  218.  
  219. Otherwise, the bit before the @ is assumed to be a mailbox in the local
  220. Newsbase. (If no domains match, then it is checked against the forwarders
  221. below).
  222.  
  223. If you wish to have an mailbox name that contains characters illegal in RISC
  224. OS filenames, then you can create an alias to convert it to something else,
  225. like I do in my alias file as shown above.
  226.  
  227. For single dialup hosts, there is likely to be a single setting which
  228. will happen to co-incide with the hostname.  For hosts serving entire
  229. domains, this is less likely. (Note that in My Setup, I accept mail for
  230. an unofficial mail domain - you won't find an MX record in the DNS for
  231. the delenn.ecs.soton.ac.uk mail domain)
  232.  
  233.  
  234. alias file format
  235. =-=-=-=-=-=-=-=-=
  236.  
  237. The format of the file is that the alias appears first on the line, and
  238. the real addresses are specified after it separated by whitespace.  If
  239. you need to use more than one line, then these continuation lines MUST
  240. start with whitespace (otherwise they are considered to be other aliases)
  241.  
  242. Although this might seem like a good way to set up a mailing list, this
  243. is NOT the case, since the original sender will be in the FROM envelope,
  244. so any forwarding errors will go to there and not to some mailing list
  245. software.
  246.  
  247. The purpose of the alias file is for *simple* rewriting and occasional
  248. duplication if you need it.  If you want to run a mailing list, then
  249. use something like !MailList.
  250.  
  251. So in My Setup mentioned above shows that any mail incoming addressed
  252. to S.N.Brodie@delenn.ecs.soton.ac.uk will be sent to snb94r.  This is
  253. useful because you can specify names which might not be acceptable as
  254. usernames to Newsbase.
  255.  
  256.  
  257.  
  258. forwarder
  259. =========
  260.  
  261. Syntax:   forwarder <"*" | F.Q. Mail Domain> <"MX" | smarthost-FQDN>
  262. Demon DU: forwarder * post.demon.co.uk
  263. Network:  forwarder * MX
  264.           forwarder * mail.smarthost.provider.org
  265. My Setup: forwarder ecs.soton.ac.uk MX
  266.           forwarder * dsse.ecs.soton.ac.uk
  267.  
  268.  
  269. This gives mail domains which are to be responded to by the software, but
  270. which are not local to this machine (ie. they need to forwarded on somewhere
  271. else, cf. localdomain).  For the vast majority of people, you will want one
  272. forwarder line (see WARNING below - having such lines may in fact
  273. contravene your provider's terms & conditions of service unless you have
  274. specifically purchased the right to forward mail).
  275.  
  276. The major purpose of the non-* entries here is when you are running FreeSMTP
  277. on the mail gateway for a domain (ie. the MX record for a domain gives
  278. the machine running FreeSMTP as one of the mail exchangers).
  279.  
  280. If there are no forwarder lines, then any mail not destined for local
  281. delivery (ie. it matched one of the localdomain lines) will be rejected when
  282. it is offered by another host (*).
  283.  
  284. If there are forwarder lines, then they are matched in order.  If the first
  285. parameter is "*", then this matches, otherwise the string has to match the
  286. bit after the @ in the destination of an incoming mail exactly.  The second
  287. parameter describes how this forwarding is to be achieved and is either the
  288. string "MX" or the FQDN of a smarthost which will do the job for you.
  289.  
  290. There are two ways of forwarding the mail - MX records, and smarthosts. Using
  291. MX records involves looking up the name of the machines which handle mail for
  292. a given mail domain (see description later in this document) and then sending
  293. the mail directly to one of those machines.  The alternative is to use a
  294. 'smarthost' (such as post.demon.co.uk) which will perform that function on
  295. your behalf (ie. it acts as an intermediate relay for you). The advantage of
  296. using MX records, is that it bypasses your provider's smarthost (less hops to
  297. the destination) and can tolerate the smarthost being down.  When MX lookups
  298. return multiple records, they are tried in turn according to the priorities
  299. specified by the DNS server. [This does seem to work, as I found out when
  300. Demon's punts weren't accepting mail and when the connection attempt to them
  301. timed out, it sent it to relay-1 instead :-) ]
  302.  
  303. (*) 'another host' could actually be your own machine.  For example, I
  304. have ArcWeb's Email configuration set up with a smarthost mail gateway
  305. of "localhost".  This means that ArcWeb will send mail by talking to the
  306. SMTP server process running on my own machine.  Thus, having no forwarder
  307. lines in my configuration would mean that I couldn't send mail that way
  308. and would have to configure a remote smarthost in ArcWeb instead.
  309.  
  310.  
  311. forwarder strategy
  312. -=-=-=-=-=-=-=-=-=
  313.  
  314. The forwarder directives which specify MX records are to be used are
  315. overridden in some circumstances, primarily for performance reasons.
  316.  
  317. If the mail has only a single recipient (or multiple recipients with the same
  318. domain) and forwarder says to use MX records, and those MX records exist,
  319. then this will happen.
  320.  
  321. If the mail has multiple recipients, then any MX directive is overridden and
  322. a smarthost is used instead *if one is defined* (because otherwise the
  323. message would have to be sent separately to each recipient).  [A future
  324. enhancement will be to still use MX records if all the destinations share a
  325. common mail exchanger]
  326.  
  327.  
  328. WARNING: Incorrect configuration of forwarder records could cause you
  329.          to be in breach of the terms & conditions of your account.
  330.          Unless you are authorised to forward mail to hosts other than
  331.          those at your provider's end of your connection, you should
  332.          only have one forwarder line:
  333.          
  334.         forwarder * post.demon.co.uk
  335.     
  336.          (where you have substituted your provider's smarthost for
  337.          post.demon.co.uk if you aren't with Demon Internet)
  338.          
  339.          The author accepts no responsibility or liability for any
  340.          such breaches of terms & conditions, nor for consequences
  341.          arising from action taken by providers against any user of
  342.          this software for such breaches even if the author has been
  343.          advised of the possibility of such breaches.
  344.  
  345.  
  346. acceptfrom
  347. ==========
  348.  
  349. Syntax:   acceptfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
  350. Demon DU: (no acceptfrom lines)
  351. Network:  (no acceptfrom lines)
  352. My Setup: (no acceptfrom lines)
  353.  
  354. ** WARNING: If you use hostnames with this command, then these must be
  355. **          resolvable when the program starts, otherwise the directive
  356. **          will be ignored.
  357.  
  358. This is used to selectively choose which remote hosts you are willing to
  359. accept mail from.  If a host other than one listed attempts to deliver
  360. mail to your machine, then it will be told that it does not have permission
  361. to deliver mail to your machine.  If there are no acceptfrom lines (as in
  362. My Setup) then any host may connect.
  363.  
  364. When specifying an IP address, you may specify the number of significant bits
  365. to be matched (as described in the rejectfrom section below)
  366.  
  367. All addresses that pass the acceptfrom directives (including the case
  368. where there are NO acceptfrom directives) are then validated against
  369. the rejectfrom directives described in the next section.
  370.  
  371. IMPORTANT:  If you have any of these fields, then you MUST include
  372. all the machine's own IP addresses and you MUST include localhost (ie.
  373. 127.0.0.1), since the outgoing sender may use these addresses when
  374. constructing error notifications and performing mail rewriting.
  375.  
  376. There is little real reason to use this facility unless you are worried
  377. about faked e-mail being sent via your site (and even then, the message
  378. is tagged with the Received line containing the IP address of the sender,
  379. allowing you to trace the source)
  380.  
  381. See also: rejectfrom, killfile
  382.  
  383. rejectfrom
  384. ==========
  385.  
  386. Syntax:   rejectfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
  387. Demon DU: rejectfrom 198.81.0.0/16
  388.           rejectfrom 152.163.172.0/24
  389. Network:  rejectfrom relay.deliverer.hackers.org
  390. My Setup: (no rejectfrom lines)
  391.  
  392. ** WARNING: If you use hostnames with this command, then these must be
  393. **          resolvable when the program starts, otherwise the directive
  394. **          will be ignored.
  395.  
  396. This is used to selectively choose which remote hosts you are NOT willing to
  397. accept mail from.  If a host covered by one of these directives, then it will
  398. be told that it does not have permission to deliver mail to your machine.  If
  399. there are no rejectfrom lines (as in My Setup) then any host may connect
  400. (subject to the acceptfrom conditions).  The Demon DU example describes that
  401. mail from 198.81.xxx.xxx and from 152.163.172.xxx will be rejected (these
  402. are the AOL mail exchangers :-)  I am not suggesting that you do this - just
  403. using it as an example of use.
  404.  
  405. IMPORTANT: You should not reject any of your machine's own IP addresses
  406. (including 127.0.0.1 (localhost)).  See also: acceptfrom, killfile
  407.  
  408. There is very little real reason to use this facility unless you have
  409. some hacker trying to send you mail, in which case you can block their
  410. IP address using this facility.
  411.  
  412.  
  413. killfile
  414. ========
  415.  
  416. Syntax:   killfile <Fully Qualified Kill File path name>
  417. Demon DU: killfile smtpserver:killfile
  418. Network:  killfile smtpserver:killfile
  419. My Setup: killfile smtpserver:killfile
  420.  
  421. This is used to kill incoming mail based on the *sender* specified
  422. in the SMTP envelope (ie. the MAIL FROM).  The file named in the
  423. directive is consulted when a new transaction is started and if
  424. the sender matches any entry, the mail is rejected.
  425.  
  426. The kill file format itself is one (wildcardable) address per line.
  427. If the kill file does not exist, nothing is killed.
  428.  
  429.  
  430. noexpand
  431. ========
  432.  
  433. Syntax:   noexpand
  434. Demon DU:
  435. Network:  noexpand
  436. My Setup:
  437.  
  438. This directive is optional and takes no parameters.  If it is present,
  439. then clients attempting an EXPN on an alias will receive a message
  440. indicating that EXPN has been explicitly disabled by the administrator.
  441.  
  442. If you don't understand the above paragraph, then you don't need this.
  443.  
  444. Normally, you'd only use this to stop people looking up the members of
  445. a mailing list of something like that.  The vast majority of people
  446. do not want this.
  447.  
  448.  
  449. noident
  450. =======
  451.  
  452. Syntax:   noident
  453. Demon DU:
  454. Network:  noident
  455. My Setup:
  456.  
  457. This directive is optional and takes no parameters.  If it is present,
  458. then the server will not attempt an ident request to the client making
  459. the connection.  See "Remote User Authentication" section below for
  460. more details of ident.
  461.  
  462. If you don't understand the above paragraph, then you don't need this.
  463.  
  464. You would only ever disable this feature for efficiency reasons.
  465.  
  466. noiconbar
  467. =========
  468.  
  469. Syntax:   noiconbar
  470. Demon DU: noiconbar
  471. Network:
  472. My Setup:
  473.  
  474. This directive is optional and takes no parameters.  If it is present,
  475. then no icon bar icon will be installed.
  476.  
  477. You would only ever disable this feature to avoid filling your iconbar.
  478. If you have this directive, the only way to stop FreeSMTP is to double-
  479. click on FreeSMTP again.
  480.  
  481.  
  482. maxhops
  483. =======
  484.  
  485. Syntax:   maxhops <maximum hop count>
  486. Demon DU:
  487. Network:
  488. My Setup:
  489.  
  490. This directive is optional and defaults to "maxhops 30".  The numeric
  491. parameter describes the maximum number of servers through which the mail is
  492. allowed to be passed before being returned to the sender as undeliverable. 
  493. Usually, mail will take at most half a dozen hops to get to the recipient. 
  494. If it is up to something more like 30 (the default here), then it is likely
  495. that a mail loop has developed (a set of servers (mis)configured to route
  496. mail for the destination domain to each other, which will just keep
  497. forwarding it back and forth forever and ever).  Once maxhops is exceeded,
  498. this server will not forward it any more, but will construct a delivery
  499. failure message and bounce it back to the sender.
  500.  
  501. Almost certainly, you do not want to override the default.
  502.  
  503.  
  504. maxsessions
  505. ===========
  506.  
  507. Syntax:   maxsessions <+ve integer>
  508. Demon DU: maxsessions 4
  509. Network:  maxsessions 4
  510. My Setup: maxsessions 4
  511.  
  512. This specifies the maximum number of sessions that may be in progress at
  513. any one time.  This is limited by the capability of the C library (and if
  514. you specify a number too large, it will be reduced to the maximum that can
  515. be supported - 4 with the current SharedCLibrary.
  516.  
  517. It is important to have this set to 4 for Demon customers, since Demon
  518. have multiple mail machines which may attempt delivery concurrently.
  519.  
  520.  
  521. Why does all email get sent to "localhost"
  522. ------------------------------------------
  523.  
  524. All e-mail sent by your machine will be sent initially to the server on your
  525. machine.  (tech: the GATE command in the work file will always be set up
  526. to be "GATE VIA:localhost").  This is deliberate, because all the mail
  527. routeing cleverness is stored in the *server* at the moment.  That software
  528. can then make the final destination decision and requeue it for sending out.
  529.  
  530. This will cause an extra Received header to be placed in the outgoing mail,
  531. and will also ensure that missing headers are inserted before the mail
  532. leaves your machine too.  
  533.  
  534. This is not a really peculiar thing to do.  Most UNIX machines I have used
  535. have done this.  It is done to simplify the coding of the mail senders and
  536. to centralise the decision making process and forwarding rule processing
  537. into a single place so that policy changes can be implemented in one go.
  538.  
  539.  
  540. Operating Advice
  541. ----------------
  542.  
  543. for people with permanent connections
  544. =====================================
  545.  
  546. Run it all the time - that's what I do.
  547.  
  548.  
  549. for people with transient dialup links
  550. ======================================
  551.  
  552. You really do want to start the TCP/IP stack and !FreeSMTP *before*
  553. connecting to the net.  This is particularly important for Demon users, since
  554. the SMTP server takes around 1 second to start up and read its configurations
  555. files and may not manage to start listening for the incoming connections
  556. before the punts attempt to deliver mail (they fail to do so, and hold on to
  557. it for a while before trying again a bit later).  This causes a slight
  558. problem with dialup lines though unless you are careful.  You *must* start
  559. the TCP/IP stack, but you do NOT need to start up the SLIP/PPP interface (if
  560. you do, your dialler won't be able to access the comms port!).  The relevant
  561. bits that must be deferred until after dialling is complete are the slattach
  562. & ifconfig commands 
  563.  
  564.  
  565. Running & Stopping !FreeSMTP
  566. ----------------------------
  567.  
  568. Run !FreeSMTP by double-clicking on the icon in the directory viewer.
  569. To stop, it double-click on the icon again (or kill SMTP Monitor in
  570. the Task display window) or choose Quit from the icon bar menu if you
  571. haven't disabled the Wimp interface (see "noiconbar" directive above)
  572.  
  573.  
  574. What to do if you get the error message:
  575.     Loopback interface is not configured/up
  576.     Loopback interface is configured - but not up
  577. -----------------------------------------------------
  578.  
  579. These two messages are new in version 1.17.  If you get them, then you
  580. will find that the program will not have started.  FreeSMTP needs the
  581. loopback interface configured.  This should have been done during your
  582. boot sequence, or whenever the TCP/IP networking software was loaded.
  583.  
  584. If you get the latter of the messages (which would be unusual unless
  585. you were fiddling around), then you need to issue the command:
  586. "*ifconfig lo0 up" at the command line or insert this in the networking
  587. startup files.
  588.  
  589. If you get the former, then you need to insert the slightly longer:
  590. "*ifconfig lo0 inet 127.0.0.1 up".
  591.  
  592. Once these commands have been executed, FreeSMTP should load.   If it
  593. still doesn't, then the chances are you that are using an old version of
  594. FreeNet.  Edit !FreeSMTP.!Run and insert the following line:
  595.  
  596. Set SMTPServer$NoSearch 1
  597.  
  598.  
  599. (See also: Why does all email get sent to "localhost")
  600.  
  601.  
  602.  
  603. Kicking the sender
  604. ------------------
  605.  
  606. The sender program (out_smtpd) is automatically launched (by SMTP Monitor)
  607. after in_smtpd has queued a mail in the outgoing queue, or the sendmail
  608. Newsbase transport has queued a mail there.  You can kick it by choosing
  609. "Kick" on the icon bar menu (see "noiconbar" directive) or double-clicking on
  610. !SendSMTP (inside !FreeSMTP).
  611.  
  612. After being loaded, it will wait 30 seconds, then 1 minute, then 2, 4, 8,
  613. then 16 minutes, and thereafter every 30 minutes. This is in addition to the
  614. other times when it is kicked manually or by the server.
  615.  
  616.  
  617. Activity Log
  618. ------------
  619.  
  620. This software contains inbuilt activity logging which it will dump to
  621. the files clnt_log & mon_log inside the !FreeSMTP directory.
  622. The amount of debugging and which debugging is controlled by a file called
  623. area_log, also inside !FreeSMTP.  This contains one string per line
  624. containing a case-sensitive string to match against those used in the code. 
  625. (* is used as a wildcard which matches every string).  Examples of these are:
  626.  
  627.     domain_init
  628.     process_mail
  629.     verify_dest
  630.     
  631. Vital messages are always logged if possible.  The file is left open
  632. whilst the server is actively writing to it and closed after a short
  633. delay if nothing is written to it, for efficiency reasons.  The location
  634. of the log file can be altered by editing !Run and changing the settings
  635. of the three <SMTPServer$xxxxxLog> variables.
  636.  
  637. These will need to be cleared out every now & again.
  638.  
  639. If you place a line containing just a single * character in this file, then
  640. everything will be logged to this file, this will help provided more details
  641. if you are having problem.  If you send me this file when reporting faults,
  642. then it is more likely that I shall be able to help.  If you do this, then
  643. the log file will grow very quickly.  Only use it when attempting to capture
  644. debug trails for me.
  645.  
  646.  
  647. References
  648. ----------
  649.  
  650. RFC821 - Simple Mail Transfer Protocol
  651.  
  652. RFC1123 - Requirements for Internet Hosts
  653.  
  654. RFC1413 - Identification Protocol
  655.  
  656.  
  657. Bug Reporting
  658. -------------
  659.  
  660. There are bug reporting features built-in to the software.  If you edit
  661. the file !FreeSMTP.area_log and add a new line at the bottom containing
  662. just an asterix (*), then all debugging information will be sent to the
  663. files, and not just the really important ones.  These document some of
  664. the decisions made by the software and will contain justification for
  665. those decisions.
  666.  
  667. Please give as much detail as possible when reporting bugs.  Include the
  668. e-mail message that caused the problem if possible.  NOTE:  If you do not
  669. wish to disclose the identities of the sender/recipient, then please feel
  670. free to overwrite it with something else - use * characters for example -
  671. but please do NOT just remove it.  If you do choose to delete parts of it,
  672. then please only delete the bits before the @ in the address.  You may
  673. also like to remove most of the message body.
  674.  
  675. Bug reports to S.N.Brodie@ecs.soton.ac.uk please
  676.  
  677.  
  678. Technical Details
  679. -----------------
  680.  
  681. I have included this section for those who are interested.  It does not
  682. matter if you do not want to read any more of this document.
  683.  
  684. MX Records Explained
  685. ====================
  686.  
  687. Briefly.  You are probably familiar with the concept of hostnames (eg.
  688. customer.demon.co.uk, www.demon.co.uk, sunsite.doc.ic.ac.uk).  The mappings
  689. between these and the 4 byte numeric IP addresses (eg. 152.78.67.42) are
  690. registered in the Domain Name System's 'A' records (A for address).  Mail
  691. domains look very much like hostnames, and in some cases happen to be the
  692. same, but this is coincidence (but arranged like that because it's easier to
  693. remember :-)   Mail domains are also registered in the Domain Name System,
  694. but they do NOT map to IP addresses, but to 'Mail eXchangers'.  These mail
  695. exchangers are simply the hostnames of machines which handle mail for that
  696. mail domain.  For example, when software is using MX records to send me mail,
  697. it looks up the MX records for 'ecs.soton.ac.uk'.  The response it will get
  698. will be something similar to:
  699.  
  700. ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
  701. ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
  702.  
  703. This indicates that bright.ecs.soton.ac.uk (which when looked up, is found to
  704. have the address 152.78.64.201) is a machine which handles mail for
  705. 'ecs.soton.ac.uk'.  landlord.ecs.soton.ac.uk is also reported as a mail
  706. exchanger (so when bright is down, we can still receive mail), but the lower
  707. number indicates that bright is the preferred exchanger, and landlord the
  708. backup.  If you perform a similar lookup on any Demon customer domain,
  709. usually you will find 4 or 5 records, with varying priorities.  Although it
  710. would appear that lots of DNS lookups are required in order to find the
  711. addresses of these mail exchangers, that is not the case typically, as the
  712. full response from the DNS for the question "ecs.soton.ac.uk IN MX" will be
  713. (if not querying one of our authoritative nameservers in Southampton):
  714.  
  715. Questions:
  716. ecs.soton.ac.uk. IN MX
  717.  
  718. Answers:
  719. ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
  720. ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
  721.  
  722. Additional:
  723. bright.ecs.soton.ac.uk IN A 152.78.64.201
  724. landlord.ecs.soton.ac.uk IN A 152.78.114.230
  725.  
  726. Authority records:
  727. dns0.ecs.soton.ac.uk    inet address = 152.78.64.201
  728. dns1.ecs.soton.ac.uk    inet address = 152.78.114.230
  729. dns0.brad.ac.uk inet address = 143.53.240.2
  730. dns0.brad.ac.uk inet address = 143.53.2.5
  731. dns1.brad.ac.uk inet address = 143.53.238.5
  732.  
  733. ie. since it is assumed that you will probably want the IN A record for
  734. each mail exchanger, the DNS server includes those records in its answer
  735. which you may need.  Since you may not 'trust' the nameserver, it also tells
  736. you machines that are the authoritative DNS servers for the ecs.soton.ac.uk
  737. internet domain.  The auth records show the names of our primary and
  738. secondary DNS servers, plus our offsite authority nameserver (an Internet
  739. requirement) at Bradford.
  740.  
  741.  
  742. Remote host authentication
  743. ==========================
  744.  
  745. When a connection is accepted, the peer IP address is looked up in the DNS.
  746. Since this lookup is initiated immediately, then the lookup is often 
  747. complete before the HELO arrives (and the HELO parameter can thus be
  748. authenticated immediately).  The domain name specified as the parameter to
  749. HELO is used in the Received header which is added by the smtp server to
  750. the incoming message, together with either the IP address of the remote
  751. host, or the name as obtained from the DNS.
  752.  
  753. NOTE: Mail will NOT be rejected if the HELO domain fails to authenticate.
  754. This is RFC-compliant behaviour (it is not allowed to reject on the basis
  755. of the HELO domain).
  756.  
  757.  
  758. Remote user authentication
  759. ==========================
  760.  
  761. When a connection is accepted, then an ident request is sent to the origin
  762. machine requesting the user identity of the sender.  (This is not done if
  763. the configuration file contains a "noident" directive).  This is logged
  764. with area "ident" (so place "ident" in area_log to see it in smtp_log).
  765.  
  766. NOTE: You cannot rely on this, particularly on the user id returned. See
  767. RFC1413 for more details about the (lack of) confidence that you should
  768. have in the ident response.
  769.  
  770. NOTE 2: You might decide to disable this, but usually only because the
  771. overhead of establishing a TCP connection to the client wastes resources.
  772. The bandwidth used is negligible though (on average about 10 bytes out,
  773. and 25-50 bytes back).
  774.  
  775.  
  776. Attacks & Security Considerations
  777. =================================
  778.  
  779. Simple denial of service attacks are prevented (limits on number of
  780. recipients for message plus limits on number of concurrent connections)
  781. The recipient limit is set to 100 (minimum requirement in RFC821)
  782.  
  783. Idling attacks are repelled by implementing the timeout strategy given
  784. in RFC1123.
  785.  
  786. Well faked e-mail can never be detected successfully, but the addition
  787. of the Received header to incoming message bodies will assist in the
  788. tracing of injection points into the SMTP system.
  789.  
  790. Two log files are generated inside !FreeSMTP.  These are called
  791. clnt_log and mon_log, and are generated by the client and monitor+server
  792. respectively.
  793.  
  794. For the general mail security considerations see RFC821 and RFC1123.  In
  795. the RISC OS environment, a further consideration is that being a single-
  796. user operating system, there is no way to prevent the Newsbase being
  797. examined directly, or the outgoing queue to be examined, unless you have
  798. taken specific measures to make this so.
  799.  
  800. RFC1123 Considerations
  801. ======================
  802.  
  803. Incoming addresses in both MAIL FROM and RCPT TO fields are automatically
  804. rewritten as per RFC1123 to strip unnecessary source routeing from them.
  805. This happens before any other processing.  (This also has the effect of
  806. stopping hackers using source routeing as a way of using you as a mail
  807. gateway, since after the rewrite, the destination domain will no longer
  808. match a localdomain, and will be rejected unless you forward for that
  809. domain)
  810.  
  811. The %-hack is supported by the address rewriter too and explicitly
  812. removed, so hackers can't use that either.
  813.  
  814. Miscellaneous
  815. =============
  816.  
  817. When spooling files if the file cannot be opened in spool.mail.text.user then
  818. spool.fail.user is used instead (and the mail is bounced if that fails too). 
  819. Files in spool.fail.user are never touched again and need to be handled
  820. manually.
  821.  
  822. I am very interested in RFC compliancy issues. E-mail
  823. me any issues you find.
  824.  
  825.  
  826. ChangeLog
  827. =========
  828.  
  829. 1.20
  830. ----
  831.  
  832. Forwarding rules code clarified - shouldn't make as many mistakes.
  833.  
  834.  
  835. 1.19
  836. ----
  837.  
  838. Loopback interface is checked for presence and uppishness
  839.  
  840. Low memory situations are handled better.
  841.  
  842. Miscellaneous fixes.
  843.  
  844.  
  845. 1.16
  846. ----
  847.  
  848. The smtp_log left open problem is definitely gone now, because the file is
  849. gone too!  Everything is dumped in mon_log instead.
  850.  
  851. Aliases with capital letters in now work
  852.  
  853. The forwarder doesn't consider you a twat for not using MX records and
  854. constantly override that decision. :-)
  855.  
  856.  
  857. 1.14
  858. ----
  859.  
  860. Local spool directory changed to be spool.mail.text.*
  861.  
  862.  
  863. 1.13
  864. ----
  865.  
  866. Bug in sender fixed - it was treated the successfully connection being made
  867. to the server as an error :-/
  868.  
  869.  
  870. 1.12
  871. ----
  872.  
  873. Full release of the not grabbing all processing time version.  Also
  874. contains a bug fix that cures a misinteraction caused by two concurrent
  875. mail deliveries.  Log file closing finally sorted.  However, because of
  876. the fix, you can't view smtp_log whilst the server is running.
  877.  
  878.  
  879. 1.10
  880. ----
  881.  
  882. Should be better behaved and not grab as much processor time, which should
  883. help people using dialup links
  884.  
  885. 1.09
  886. ----
  887.  
  888. Log file should be closed successfully now
  889.  
  890.  
  891. 1.06
  892. ----
  893.  
  894. Mail can now be sent even without a terminating linefeed.  This would have
  895. caused mail to not be delivered.
  896.  
  897. 1.05
  898. ----
  899.  
  900. DNS Resolver bug fix
  901.  
  902. 1.04
  903. ----
  904.  
  905. RFC compliancy fix: doesn't try the A record if all the MX records fail.
  906. A records only used if no MX records were found.
  907.  
  908. Extra debug information put in to try to determine the cause of some
  909. apparent premature timing out.
  910.  
  911. Activity log notes in this document updated to cover bug reports.
  912.  
  913.  
  914. 1.03
  915. ----
  916.  
  917. VRFY fixed again!  It was rejecting non-local single recipient aliases
  918. because Newsbase was saying that the user was unknown.
  919.  
  920.  
  921. 1.02
  922. ----
  923.  
  924. Fixed domain name processing to not add surplus > characters
  925.  
  926. EXPN procession now works properly again
  927.  
  928.  
  929. 1.01
  930. ----
  931.  
  932. Fixed acceptfrom and rejectfrom handling - the bitfield masks were
  933. the wrong way around 
  934.  
  935.  
  936. 1.00
  937. ----
  938.  
  939. TRACE removed from the sendmail transport!!
  940.  
  941. maxhops added
  942.  
  943. Vital missing headers are added to incoming mail
  944.  
  945.  
  946. 0.11
  947. ----
  948.  
  949. You can disable the GUI by adding 'noiconbar' to the configuration file
  950.  
  951. Some of the log messages are clearer
  952.  
  953. Bug in sendmail transport file corrected
  954.  
  955.  
  956. 0.10
  957. ----
  958.  
  959. Very simple Wimp interface added
  960.  
  961. Some log messages have been changed to make them sound less fatal (some
  962. are purely informational but had alarming sounding overtones)
  963.  
  964. in_smtpd's sendmail reads the smtp-conf file to determine how to send
  965. mail to single recipients, instead of defaulting to MX records (when
  966. no gateway can be found, and none was given in Newsbase, multiple
  967. mails are generated to all of the recipients via MX records)
  968.  
  969.  
  970.  
  971. 0.09
  972. ----
  973.  
  974. Multi-line responses were confusing the SMTP sender because I'd got a
  975. condition test round the wrong way :-(
  976.  
  977. Lock files removed - the task list is scanned instead.
  978.  
  979. Long lines were confusing things all over the place.  Although illegal,
  980. some clients still generate this, so I allow them now too.
  981.  
  982. The socket sender had every chance of crashing if a line was to be
  983. transmitted which was longer than 256 characters!  This is now 
  984. upped to 1024 characters (something which calling routines already
  985. enforce)
  986.  
  987. SMTP Monitor uses an exponential backoff retry algorithm for sending mail
  988. when it is first started - it delays 30 seconds, then 1 minute, then 2,
  989. then 4, then 8, then 16, then every 30 minutes.  It can still be launched
  990. manually by running !SendSMTP and will be launched whenever you send mail
  991. locally.
  992.  
  993.  
  994.  
  995. Please e-mail me any problems: snb94r@ecs.soton.ac.uk
  996.  
  997.  
  998. --
  999. Stewart Brodie
  1000. February 1997
  1001.